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(54) Systehn and method for allowing disparate naming service providers to dynamically join a 
namii^federation 



(57) The present invention provides an improved 
Federated Naming Framework System which includes 
a Federated Naming Service Provider Interface ("FN 
SPI") for four (4) kinds of Name Services (Atomic Name, 
Compound Name, Partial Composite Name and Com- 
posite Name) along with a mechanism, designated the 
"FN Framework", which sits between the Client applica- 
tion and these Name Services and supports the trans- 
lation and administration of calls for resolution of com- 
posite names to allow Client applications to make ap- 
propriate use of the available FN SPIs (there may be 
more than one FN SPI in any given system). The im- 
proved Federated Naming Framework System provides 
mechanisms to define and process strong and weak 
separation in the determination of naming system 
boundaries. Moreover, the present invention allows sys- 
tem implementors to install new naming services either 
statically or dynamically without disruption of the Client 
applications 
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Description 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object oriented systems. Specifically, the present inven- $ 
tion relates to the field of naming services and directory 
systems in distributed computing systems. 

In client-server computing, typically there is a set of 
computers that can communicate with one another 
through a network connecting the computers. Some of io 
these computers act as providers of services or func- 
tionality to other computers. The providers of such serv- 
ice or functionality are known as "servers, ■ and the con- 
sumers of such service or functionality are called "cli- 
ents. 0 The client-server model also generalizes to the 7 $ 
case where distinct programs running on the same com- 
puter are communicating with one another through 
some protected mechanism and are acting as providers 
and consumers of functionality. 

In an object oriented system, an object is a compo- 20 
nent comprising data and operations which can be in- 
voked to manipulate the data. The operations are in- 
voked on the object by sending calls to the object. Each 
object has an object type. The object type defines the 
operations that can be performedon objects of that type. 25 
The object operations are implemented independent of 
the objects themselves. Additionally, one object type 
may inherit the object operations defined and imple- 
mented for other object types. For further description of 
object oriented design and programming techniques 30 
see "Object-oriented Software Construction" by Ber- 
trand Meyer, Prentice-Hall 1 988. 

In object oriented distributed systems based upon 
the client-server model, there exist servers that provide 
object oriented interfaces to their clients. These servers 35 
support objects consisting of data and the associated 
program instructions. Clients may obtain access to 
these objects and may execute calls on them. These 
calls are transmitted to the server from the client. At the 
server these calls are executed via the software asso- <*o 
ciated with the object. The results of these calls are then 
transmitted back to the client. 

Client applications or programs refer to particular 
objects by means of object handles or object names. An 
object name is used to locate an object (the "target ob- 
jecf) so that calls may be executed on it. Client pro- 
grams are typically provided with object names by other 
programs or inherit them at program initiation. If a given 
client program has an object name for a particular object 
then that client program can pass a copy of that object so 
name to another client program. The second client pro- 
gram can then use the object name to access the object. 
Clients do not have information about the location of the 
object or the object's implementation which may be on 
some computer anywhere in the distributed computer 55 
system. The client's call to the object by means of the 
object's name is enabled by a "Naming or Directory 
Service. " 



A Naming or Directory service is a fundamental fa- 
cility in any computing system. It is the means by which 
names are associated with objects, and by which ob- 
jects are found given their names. The naming service 
provides operations for: 

o associating (binding) names to objects 

o resolving (looking up) names to objects 

o removing bindings, listing names, renaming, etc. 

In addition to these basic naming operations, the service 
can also provide operations for dealing with attributes: 

o examining attributes associated with named ob- 
jects 

o modifying attributes associated with named objects 
o searching for objects using attributes, etc. 

In traditional systems, a naming service is seldom 
a separate service. It is usually integrated with another 
service, such as a file system, database, desktop etc. 
For example, a file system includes a naming service 
for files and directories; and a spreadsheet has a nam- 
ing service for cells and macros. 

In a large distributed computing environment, there 
are typically many disparate naming systems that can 
either be accessed separately or cooperatively to re- 
solve composite names. A "composite name" is a 
name that spans multiple naming systems. It consists 
of an ordered list of zero or more components. Each 
component is a string name from the name space of a 
single naming system. Moreover, a system has been de- 
veloped for a protocol and process for combining names 
from disparate naming systems into a "federated nam- 
ing system 1 ' which can be implemented to facilitate res- 
olution of "composite names". See United States Pat- 
ent Number 5,377,323 issued December 27, 1994 to 
Rangaswamy Vasudevan titled "Apparatus and Method 
for a Federated Naming System which Can Resolve a 
Composite Name Composed of Names from Any 
Number of Disparate Naming Systems" which is incor- 
porated fully herein by reference. X/Open, an independ- 
ent, worldwide, open systems organization supported 
by most of the world's largest information systems sup- 
pliers, user organizations and software companies have 
adopted a standard defined way for clients (application 
programs) to access what is known as "federated nam- 
ing systems." See the Preliminary Specification titled 
"Federated Naming: The XFN Specification" July 1994, 
X/Open Company Limited, ISBN: 1-85912-045-8 which 
is incorporated fully herein by reference. Federated 
Naming consists of a range of application program in- 
terfaces that include operations for resolving composite 
names to object references, binding composite names 
to object references, and listing naming contexts which 
contain name-to-reference bindings. In addition, the in- 
terfaces include operations for manipulating composite 
names and object references. 
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There must be a way for naming and directory serv- 
ice providers to incorporate their individual naming and 
directory operations into the federated naming system 
operations, and to allow new and arbitrary naming and 
directory systems to be made accessible to applications s 
at run-time, without requiring recompilation of applica- 
tions, re-linking or having to stop the application. 

For example, while the interfaces defined in the X/ 
Open XFN specification greatly simplify client programs 
that need composite and individual access to autono- 10 
mous naming and directory systems, it is still difficult for 
naming or directory service provider programs to incor- 
porate their respective services in the naming federa- 
tion. That is, the operations for the federated naming 
system make it relatively straightforward for the client 1$ 
program to use a command of the type u objectT= ctx- 
>OpenLookup(name, &status)"\o obtain a reference to 
the object named by the Composite Name "name" rel- 
ative to the context "ctx". However at the present time, 
it is very difficult to integrate a new naming or directory 20 
sen/ice provider (for the purposes of the discussion to 
follow, the term naming service provider will be used in 
place of naming or directory service provider, without 
loss of generality) into an existing system. This frequent- 
ly involves changing/modifying/augmenttng the individ- 25 
ual existing naming service provider programs. That is, 
the modifications have not been straightforward to ac- 
complish the tasks related to responding to a command 
of the type "objectT= ctx->OpenLookup(name, &status) 
" wh e re in th e naming service provider p rogram m u st re- 30 
turn ah object reference bound to head(name) in context 
ctx if "name" is an atomic name , and otherwise must 
return an object reference to a next context (say context 
cty) by returning head(cry) and a tail(name-cry). This 
problem is even more difficult if the incorporation of 35 
these modifications into the naming service provider has 
to be achieved without requiring that client applications 
be recompiled, or without requiring that client applica- 
tions be stopped and restarted whenever a naming serv- 
ice provider program for a new naming service needs to 40 
be called as a result of the operations required to proc- 
ess a command of the type "objectT~ctx~>OpenLookup 
(name, &status)". 

The prior art does not define a uniform method for 
service provider programs to incorporate arb itrary nam- 45 
ing and directory systems so that clients may automat- 
ically access them either individually or composite ly. A 
CD-ROM entitled "The 1 994 Solaris Developer Confer- 
ence" created by SunSoft, a Sun Microsystems, Inc. 
company and dated April 1 994 was distributed at a Sun so 
Developers Conference in San Francisco, April 5-7, 
1994. This CD-ROM included a number of demonstra- 
tion binary programs and a paper in postscript form, en- 
titled "Federated Naming Service" by SunSoft dated 
April 1994. This "Federated Naming Service" paper is ss 
fully incorporated herein by reference. This paper de- 
scribed the Federated Naming system and related prob- 
lems as summarized above and in addition, in Chapter 
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5, the paper described a Service Provider Framework 
that supports the federation of Federated Naming Sys- 
tem-conformant naming services in Solaris. Solaris is 
the Operating System Environment product produced 
and sold by Sun Microsystems, Inc. This chapter 5 de- 
scribed the framework, how implementors could use the 
framework to federate existing and new naming servic- 
es, and how implementors could use a toolkit described 
therein to alleviate the task of federated naming servic- 
es. Unfortunately, the mechanisms defined in this paper 
did not address the fact that naming systems within a 
federation have different ways of indicating where the 
boundaries between naming systems are. There was 
no way to indicate how names from different naming 
systems within a federation are syntactically separated 
within a composite name, effectively identifying where 
the naming system boundaries lie. The present inven- 
tion provides an improved Federated Naming Frame- 
work mechanism wherein strong and weak separation 
are defined and mechanisms provided to determine 
where these naming system boundaries are. 

Accordingly, the present invention defines a system 
and method for allowing a developer/maintainer to inte- 
grate disparate naming service provider programs into 
an existing system so that clients can access the newly 
integrated naming or directory service automatically and 
without having to be disrupted. 

The present invention overcomes the problems of 
implementing naming service providers into an existing 
distributed computing system as required by federated 
naming system operations wherein naming system 
boundaries are not defined. A system and method are 
disclosed to 

• simplify the way in which naming service providers 
incorporate their individual naming and directory 
operations into the federated naming system oper- 
ations; and 

• allow new and arbitrary naming and directory serv- 
ices to be made accessible to applications at run- 
time, without requiring re-compilation, re-linking or 
having to stop the application, in other words, with- 
out disruption; and 

• to provide naming system mechanisms configured 
to indicate support for strong or weak separation in 
their respective naming systems. 

The present invention allows incorporation of a 
naming service at the level of composite naming or 
atomic naming to suit the service provider's needs. The 
method and apparatus also include a way to identify and 
invoke the appropriate naming or directory service pro- 
vider implementation at run -time. This means that an 
application may have the benefit of traversing multiple 
disparate naming systems at run-time without a-priori 
knowledge of their existence or location. The dynamic 
capability of the apparatus further allows for arbitrary 
naming service providers to be incorporated and thus 
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be made accessible without the application having to be 
disrupted. 

In one aspect of the present invention, a Federated 
Naming Framework System is disclosed for use in a dis- 
tributed computing system. The Federated Naming 
Framework System includes a federated naming frame- 
work mechanism which acts as the intermediate layer 
between the client application and the one or more nam- 
ing services that need to be federated, and which in- 
cludes one or more naming service mechanisms con- 
figured to indicate support for strong or weak separation 
in their respective naming systems. 

In another aspect of the present invention, the Fed- 
erated Naming Framework System also includes a nam- 
ing service provider interface configured to communi- 
cate with one or more naming service providers. 

In yet another aspect of the invention, a method is 
disclosed for providing a mechanism to permit naming 
service providers to be added to an existing system with- 
out disruption of the existing clients. 

In still another aspect of the invention, a computer 
program product having a computer usable medium 
which contains computer readable code mechanisms 
embodied therein is disclosed, which computer reada- 
ble code mechanisms include a Federated Naming 
Framework System which includes a federated naming 
framework mechanism which acts as the intermediate 
layer between the client application and the one or more 
naming services that need to be federated, and which 
includes one or more naming service mechanisms con- 
figured to indicate support for strong or weak separation 
in their respective naming systems. 

The objects, features and advantages of the system 
of the present invention will be apparent from the follow- 
ing description in which: 

Figure 1 illustrates a typical computer workstation 
of the type used in conjunction with the current inven- 
tion. 

Figure 2 illustrates a typical configuration of a dis- 
tributed computer system for use in conjunction with the 
current invention. 

Figure 3 illustrates a typical client-server relation- 
ship in a distributed system. 

Figure 4 illustrates a typical client-server relation- 
ship in a common host system. 

Figure 5 illustrates a context object. 

Figure 6 illustrates an alternate view of a context 
object. 

Figure 7 illustrates a functional relationship of a typ- 
ical naming service provider to a client 

Figure 8 illustrates a system having multiple nam- 
ing service providers. 

Figure 9 illustrates a structure for a system having 
multiple naming service providers according to the 
present invention. 

Figure 10 illustrates another view of the present in- 
vention showing examples of contexts implementations 
for several different naming services. 



Figure 11 illustrates how the Federated Naming 
(FN) Framework implements the context interface using 
the Partial Composite SPI. 

Figure 12 illustrates the use of compound names 

5 and the "next naming system" pointer. 

Figures 1 3a, 1 3b & 1 3c illustrate a flow chart show- 
ing the general operations of a system implementing the 
Federated Naming Framework. 

The detailed descriptions which follow are present- 
to ed largely in terms of algorithms and symbolic represen- 
tations of operations on data bits within a computer 
memory. These algorithmic descriptions and represen- 
tations are the means used by those skilled in the data 
processing arts to most effectively convey the sub- 

*5 stance of their work to others skilled in the art. 

An algorithm is a self -consistent sequence of steps 
leading to a desired result. These steps are those re- 
quiring physical manipulations of physical quantities. 
Usually, though not necessarily, these quantities take 

20 the form of electrical or magnetic signals capable of be- 
ing stored, transferred, combined, compared, and oth- 
erwise manipulated. It proves convenient at times, prin- 
cipally for reasons of common usage, to refer to these 
signals as bits, values, elements, symbols, characters, 

25 terms, numbers, or the like. It should be bourne in mind, 
however, that all of these and similar terms are to be 
associated with the appropriate physical quantities and 
are merely convenient labels applied to these quantities. 
Further, the manipulations performed are often re- 

30 ferred to in terms, such as adding or comparing, which 
are commonly associated with mental operations per- 
formed by a human operator No such capability of a 
human operator is necessary, or desirable in most cas- 
es, in any of the operations described herein which form 

35 part of the present invention; the operations are ma- 
chine operations. Useful machines for performing the 
operations of the present invention include general pur- 
pose digital computers or similar devices. In all cases 
there should be bourne in mind the distinction between 

40 the method operations in operating a computer and the 
method of computation itself. The present invention re- 
lates to method steps for operating a computer in 
processing electrical or other (e.g., mechanical, chemi- 
cal) physical signals to generate other desired physical 

45 signals. 

The present invention also relates to apparatus for 
performing these operations. This apparatus may be 
specially constructed for the required purposes or it may 
comprise a general purpose computer as selectively ac- 

so tivated or reconfigured by a computer program stored 
in the computer. The algorithms presented herein are 
not inherently related to a particular computer or other 
apparatus. In particular, various general purpose ma- 
chines may be used with programs written in accord- 

55 ance with the teachings herein, or it may prove more 
convenient to construct more specialized apparatus to 
perform the required method steps. The required struc- 
ture for a variety of these machines will appear from the 
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description given. 

A system and method are disclosed tor incorporat- 
ing arbitrary naming services into a naming federation 
in a distributed computing system. In the following de- 
scription, for purposes of explanation, specific data and 
configurations are set forth in order to provide a thor- 
ough understanding of the present invention. The pre- 
ferred embodiment described herein is implemented for 
use in the Solaris© Operating System created by Sun 
Microsystems®, Inc. (Solaris is a trademark, and Sun 
Microsystems is a registered trademark of Sun Micro- 
systems, Inc.) However it will be apparent to one skilled 
in the art that the present invention may be practiced 
without the specific details and may be implemented in 
various computer systems and in various configura- 
tions, or makes or models of tightly-coupled processors 
or in various configurations of loosely-coupled multi- 
processor systems. 

The present invention is a system and method for 
a Federated Naming Framework ("FN Framework") sys- 
tem, which includes a set of standardized Federated 
Naming Service Provider Interfaces ("FN SPIs 0 ). The 
present invention allows incorporation of a naming serv- 
ice at different levels ranging from composite naming to 
atomic naming to suit the service provider's needs. The 
method and apparatus also includes a way to identify 
and invoke the appropriate naming service provider im- 
plementation at run-time. This means that an application 
may have the benefit of traversing multiple disparate 
naming systems at run-time without a-priori knowledge 
of their existence or location. The dynamic nature of the 
apparatus and method allows for arbitrary naming serv- 
ice providers to be incorporated and thus be made ac- 
cessible without the application having to be disrupted. 

The environment in which the present invention is 
used encompasses the general distributed computing 
system, wherein general purpose computers, worksta- 
tions, or personal computers are connected via commu- 
nication links of various types, in a client-server arrange- 
ment, wherein programs and data, many in the form of 
objects, are made available by various members of the 
system for execution and access by other members of 
the system. Some of the elements of a general purpose 
workstation computer are shown in Figure 1 , wherein a 
processor 1 is shown, having an Input/output ("I/O") sec- 
tion 2, a central processing unit ("CPU") 3 and a memory 
section 4. The I/O section 2 is connected to a keyboard 
5, a display unit 6, a disk storage unit 9 and a CD-ROM 
drive unit 7. The CD-ROM unit 7 can read a CD-ROM 
medium 8 which typically contains programs 1 0 and da- 
ta. The computer program products containing mecha- 
nisms to effectuate the apparatus and methods of the 
present invention may reside in the memory section 4, 
or on a disk storage unit 9, or on the CD-ROM 8 of such 
a system. Figure 2 illustrates a typical multi-processor 
distributed computer system wherein independent com- 
puters 20, 22 and 24 are connected to each other and 
possibly to a shared memory unit 28 via a communica- 



tion link 26. Figure 3 illustrates a typical object oriented, 
client server arrangement; wherein a user 30 can initiate 
a client application 34 on a first computer 32. The client 
application 34 places a call 40 on an object reference 

s 36 which points to an implementation of the object ( 
also referred to as the "target object") 46 on a second 
computer (the server) 50. The call 40 is passed to the 
communication control mechanism 38 which sends the 
call to the server 50 on which the object implementation 

10 46 is located. This object implementation mechanism 46 
originally creates the object reference 36 and makes it 
available to users, usually when the object implementa- 
tion is first created. Upon completion of processing the 
call, the object implementation 46 will return a message 

is or the results of a desired operation via the communi- 
cation link 42 to the originating client application 34. This 
client-server model may also function in a single proc- 
essor unit wherein the communications mechanism 
functions are performed by the operating system (62 In 

20 Figure 4). 

The salient federated naming system concepts that 
are germane to this invention are: 

Every name is generated by a set of syntactic rules 
called a naming convention. An atomic name is an 

25 indivisible component sequence of one or more charac- 
ters defined by a naming convention. A naming conven- 
tion defines all possible atomic names. A compound 
name is a sequence of one or more atomic names. A 
composite name is a sequence of one or more com- 

30 pound names. Each compound name belongs to a dif- 
ferent naming system. 

A context is an object that contains a set of bind- 
ings with distinct atomic names. Every context has an 
associated naming convention. A context provides a 

3$ iookup (resolve) operation that returns the reference 
to an object. It may also provide operations that bind 
names, unbind names, change names, list bound 
names, examine and manipulate attributes associated 
with named objects, etc. 

40 A naming system is a connected set of contexts of 
the same type (having the same naming convention) 
and providing the same set of operations with identical 
semantics. 

A federated naming system is a set of autono- 
45 mous naming systems that cooperate through a stand- 
ard interface to implement name resolution of compos- 
ite names. Thus, a federated naming system is a con- 
nected set of contexts spanning more than one naming 
system. The connection between two naming systems 
50 in a federation can be expressed and implemented us- 
ing the notion of a next naming system pointer. A next 
naming system pointer contains reference information 
on how to reach the next naming system in the federa- 
tion. 

55 Naming systems within a federation are separated 
by naming system boundaries. Composite names are 
used to name objects in a federated naming system. 
The terms strong separation and weak separation 
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are used to describe how names from different naming 
systems within a federation are syntactically separated 
within a composite name, effectively, identifying where 
the naming system boundaries lie. In strong separa- 
tion, the composite component name separator is used 
to indicate the naming system boundary. In weak sep- 
aration, the composite component name separator 
does not necessarily indicate a naming system bound- 
ary; the naming system boundary is determined dynam- 
ically as resolution proceeds (wherein we speak of dy- 
namic weak separation), or statically through the use 
of syntactic rules particular to a naming system (which 
is referred to as static weak separation). Strong and 
weak separation are properties of a particular naming 
system. Strongly and weakly separated naming sys- 
tems may co-exist within a single federation. 
Since this concept of a naming context is fundamental 
to the general idea of naming systems, several different 
views of the concept of context will now be illustrated. 
Referring now to Figure 5, a context object is depicted. 
Context object 382 is shown, containing various meth- 
ods 386 and a state 384 which comprises a List of 
names which are bound to object references. The object 
references may point to an object such as object 394, 
or they may point to other context objects 388, 396 
which themselves have similar operations (methods) 
and state containing names bound to other references, 
for example, such as those in context object 396 point- 
ing to object 392, and those in context object 388 point- 
ing to object 390. It should be understood that these ob- 
jects 394, 392, and 390 are implementations of the ob- 
jects whose locations are indicated by the references 
bound to the object names. 

Referring now to Figure 6 an alternate view of a 
context object is depicted 400. The context object 400 
contains a table 401 which maintains a set of name-to- 
object reference associations (also called name bind- 
ings). In the preferred embodiment, names have mean- 
ing only in the context in which they are used. Thus an 
object reference may be bound to several different 
names in several different context objects at the same 
time. A client of a typical naming service performs nam- 
ing operations via methods identified in a method table 
403 of the context object 400. In the preferred embodi- 
ment, for example, a context object has methods to 
lookup 408 the name of an object, which means to look 
up the object reference bound to the given name within 
a context; to bind 406 a name to an object, thereby as- 
sociating a name with the reference of an object; to Ust 
405 the names and associated references; etc. 

As indicated in Figure 5, context objects may point 
to other context objects; that is, a name in one context 
object may be bound to the reference of a second con- 
text object. Binding one context object within another 
context object creates a naming graph, which is a direct- 
ed graph with nodes and labeled edges, where the 
nodes with outgoing edges are contexts. When an edge 
leads to a context in another naming system, this cre- 
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ates a naming graph that spans multiple naming sys- 
tems. In other words, name space composition, or the 
creation of a federated name space, in which one 
name space is attached to another name space, has oc- 
s cur red. 

Naming Service Providers 

Different naming systems use different mecha- 

10 nisms to bind context objects together and to map object 
names to the appropriate object implementation. The 
mechanisms used to provide the interface between a 
client and this naming structure is the Naming Service 
Provider. In Figure 7 a functional relationship 800 be- 

is tween these elements is shown. The application (client) 
802 typically executes a call on a context object. This 
call 804 contains a name, the operation to perform, and 
one or more additional parameters required by the op- 
eration, for example "name foo, operation A m . Assume 

20 for this example that foo is an atomic name and that the 
operation is to be effected on the context object named 
by foo. [If the operation is to be performed on the penul- 
timate context (such as is the case for operations like 
bind) rather than the context named by foo, then there 

25 would be slight variations to the following description. 
Namely, the operation A would be performed by context 
object 810 rather than 820.] The call 804 is typically di- 
rected to the Naming Service Provider 806 which first 
locates the context object supplied. It then passes 

30 "name foo r operation A° 808 to that context object 81 0. 
The context object 810 tries to map the object name foo 
into the location of the implementation of the object. The 
context object 810 finds the name foo in its name table 
812 bound to the reference locn 814 and returns it 816 

35 to the Naming Service Provider 806. The Naming Serv- 
ice Provider 806 then uses the reference locn 816 to 
generate a pointer to the address of the implementation 
820 of the object foo and gives it the operation A 81 8. 
The context implementation 820 performs the method 

40 824 corresponding to operation A 822 and returns a re- 
sult 826 to the Naming service Provider 806, which 
passes the result 828 to the calling client 802 thereby 
completing the original operation call request. Other em- 
bodiments provide for the context implementation 820 

45 to return any results of the called operation directly to 
the calling client application 802. It will be recognized 
by those skilled in these arts that the Naming Service 
Provider 806 may manage significantly more activities 
if there are multiple context objects involved in the map- 

50 ping of the original name to the location of the imple- 
mentation. 

A more complex situation arises where multiple 
Naming Service Providers are involved. This is a case 
where a composite name spans multiple naming sys- 
55 terns. Consider the example shown in Figure 8. The 
system 900 illustrated in Figure 8 shows a system 
wherein the client application 902 issues a call on an 
object having a composite name yx/i;j 904 to Naming 
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Service Provider M 906. The composite name yx/i:j con- 
sists of two components, yx and /.y;the first component 
yx is a compound name from a name space that has a 
right-to- left, dot-separated name syntax, while the sec- 
ond component i:j is a compound name from a name 
space that has a left-to-right, colon-separated name 
syntax. 

This Naming Service Provider M 906 attempts to 
resolve the name yx/i:j through . context object A 908 
wherein the name portion x910 is resolved to the refer- 
ence 912, which points to context object B 914. In con- 
text object B 914, the name portion /916 is resolved to 
an entry 918, which is a reference to a context in another 
naming system. Because Naming Service Providers 
can only deal with contexts within the same naming sys- 
tem, context object B 914 sends a response 920 to con- 
text object A 908 and thence 922 to Naming Service Pro- 
vider M 906 which says 924 "I cannot resolve the rest 
of the name (/y). " In this case the Naming Service Pro- 
vider M 906 does not know about Naming Service Pro- 
vider N 930 and so must return a message 926 to the 
client application 902 which says "I cannot resolve the 
name of the object you requested." If the Client 902 
knows to call the second Naming Service Provider N 
930, a call can be made to resolve the remainder ol the 
composite name i:j 928. In this example, the second 
Naming Service Provider N 930 knows how to resolve 
the balance of the name and the called objects imple- 
mentation 958 is ultimately called and the call ends suc- 
cessfully. 

In the example described above in Figure 8, the Cli- 
ent 902 must be modified whenever it is necessary to 
add another Naming Service Provider to the system. It 
had to know to invoke Naming Service Provider N 930 
to resolve the rest of the name i:j. As other Naming Serv- 
ice Providers are added, the Client needs to be modified 
to know about them. Furthermore, the Client 902 is also 
administering the calls to the different Naming Service 
Providers. It is more desirable that the Client applica- 
tions and their programmers do not have to deal with 
handling and adminstering these different Naming Serv- 
ice Providers. It is this problem that is addressed by the 
present invention. 

Overview of Present Invention 

Following the definitions given for the different 
forms of names — atomic, compound and composite - 
described earlier in the Background section, the 
present invention provides a Federated Naming Serv- 
ice Provider interface (FN SPI) for four (4) types 
(Atomic Name, Compound Name, Partial Composite 
Name and Composite Name), along with a mechanism, 
designated the Federated Naming Framework (FN 
Framework), which is present between these interfaces 
and clients, to support the translation and administration 
of calls for resolution of composite names. This allows 
client applications using the Federated Naming API to 
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make appropriate use of the available FN SPIs (there 
may be more than one FN SPI in any given system). 
The present invention allows system implementors to 
install new naming services dynamically without disrup- 
5 tion of the client applications. 

One view of the present invention is shown in Fig- 
ure 9. Figure 9 indicates a system 1000 showing the 
system of Figure 8 as handled by the FN Framework 
1004. In system 1000 the FN Framework 1004 is located 
to between the client application 1002 and the Naming 
Service Providers 1012, 1030 and performs all of the 
functions necessary to resolve composite names which 
require partial resolutions from both Naming Service 
Providers 1012, 1030. It will be clear to those skilled in 
. 15 these arts that a FN Framework 1004 which is capable 
of interfacing with multiple Naming Service Providers 
through FN SPIs would provide significant utility to sys- 
tems implementing a federated naming system com- 
prising multiple disparate naming services. 

20 

Details of the Present Invention 

A. Architecture 

25 The invention takes advantage of the fact that nam- 
ing context is the fundamental naming concept. Associ- 
ated with each named context object is an implementa- 
tion for it — this is referred to as the context implemen- 
tation. Each context implementation provides opera- 
te tions (like lookup, bind, associating attributes and ex- 
amining them, etc) functionally equivalent to those in the 
context interface (see US Patent # 5,377,323 described 
above). The context implementation makes these oper- 
ations available through a Federated Naming Service 
35 Provider interface (FN SPI), which is a contract be- 
tween the FN Framework and the context implementa- 
tion. There are four kinds of FN SPIs, depending on the 
capabilities of the context implementation, so that differ- 
ent naming service needs are properly satisfied. The 
40 four kinds of FN SPIs are: 

Composite Name SPI, 
Partial Composite Name SPI, 
Compound Name SPI, 
45 Atomic Name SPI. 

Operations involving composite names require 
composite name resolution. The FN Framework ena- 
bles composite name resolution through different con- 

50 texts, possibly through different naming systems, by us- 
ing the context implementations associated with each 
context involved. Association between a name and its 
context handle is done in the following manner. The FN 
API supplies an operation (OpenLookup) which returns 

55 the reference bound to a name. Each FN SPI contains 
a constructorQ operation, which the FN Framework in- 
vokes (for each context implementation) in order to get 
a context handlato the context (object handles and con- 
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structors are described in the aforementioned text "Ob- 
ject-Oriented Software Construction" by Betrand Meyer, 
Prentice-Hall, 1986). Using this reference, the FN 
Framework loads in the context implementation associ- 
ated with the reference and invokes the constructorQ 
operation from it. At this point, the FN Framework has 
a context handle to a context object. The FN Framework 
manages composite name resolution by alternatively re- 
solving component(s) from the composite name and 
then obtaining a context handle to the context object 
named by the component(s). Eventually, all the compo- 
nents of the composite name are consumed and the tar- 
get context upon which the target operation is to take 
place is reached. The FN Framework then invokes the 
target operation on the target context (with arguments 
appropriate for that operation) and returns the results of 
the invocation to the client application. In the preferred 
embodiment, the following illustrates a code fragment 
of how the constructor might be called: 

ctx = constructor(reference); 
where 

ctx is a handle to a context object 
reference is a reference obtained by looking up a 
name. 

(this is discussed in more detail in Section Context Im- 
plementation Linkage below). 

The following discussion will describe the three key 
components of this invention: 

* theFNSPI, 

* the FN Framework, 

* context implementation linkage. 

B. The Federated Naming Service Provider Interface 

The Federated Naming Service Provider Interface 
(FN SPI) provides a simplified way for naming and di- 
rectory service providers to incorporate their naming 
and directory operations into the federated naming sys- 
tem operations. Naming service providers are insulated 
from knowledge about other naming service providers 
on the same system and only need to supply operations 
defined in the SPI that they are using. 

As described above, each FN SPI contains a con- 
structorQ operation that each context implementation 
must supply. 

Each operation in the FN SPI has a status argument 
that is set by the context implementation. All context im- 
plementations set the status argument in the following 
way. If the operation is to be continued by the FN Frame- 
work, the context implementation must set the status (or 
status code) to CONTINUE and set the following two 
fields of the status object as follows: 

rref (the resolved reference field) is a reference to 
the context in which to continue the operation. 
mame (the remaining name field) is set to the name 
to be processed in the context pointed to by rref. 



' This information allows the FN Framework to continue 
processing of the composite name to completion. 

The following describes each of the four kinds of FN 
SPIs. 

5 

Composite Name SPI 

Naming service providers that want to handle com- 
plete composite name resolution should provide the 

to Composite Name SPI. The context implementation pro- 
vides an implementation for the context interface 
(ctxJookupQ, ctx_bind(), ctx_unbind(), and so on) di- 
rectly and must be able to handle complete composite 
name resolution, across any naming system boundary 

is and return the answer to the client. 

Partial Composite Name SPI 

The Composite Name SPI required the underlying 

20 context implementation provider to carry its operations 
to their conclusion, even if that involves recursive eval- 
uation. The recursive model is a convenient one for the 
client, but recursive evaluation is not always desirable 
or even possible. Naming service providers that want to 

2S only resolve a composite name partially should provide 
the Partial Composite Name SPI. 

Context implementations that offer the Partial Com- 
posite Name SPI provide implementations for opera- 
tions on partial composite names. Such context imple- 

30 mentations are not required to handle a composite 
name in its entirety. Any remaining unused components 
of the composite name are returned by the context im- 
plementation along with status information indicating 
how theoperation should be continued to the FN Frame- 

35 , work. The FN Framework (described in detail below) 
then interprets this status information and invokes the 
next Naming Service Provider to continue the operation. 

The Partial Composite Name SPi defines a set of 
operations {pJookupQ, p_list_names() etc.) mirroring 

40 the operations in the context interface to be used by the 
FN Framework. Figure 11 depicts an exemplary Partial 
Composite Name Resolution. Operations with the "p_ n 
prefix (e.g. pJookupQ are invoked on a context ctx, and 
take as input a composite name, name, and returns <op- 

45 eration results> and status, if a p_ operation did not 
complete the operation and require that the operation 
•be continued in another context, it sets the status object 
with the following information: 

so - set status code to CONTINUE, to indicate that the 
operation is to be continued 

set the remaining name part (mame) in status to be 
part of name that needs further processing 
set the resolved reference part (rref) in statusto be 
ss the reference of the name resolved thus far. 

This status information is returned by the context imple- 
mentation to the FN Framework, which updates the 
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name argument to be rname, and updates ctxio be the 
context handle of the context identified by rref. The up- 
dated name and ctx arguments are then used to contin- 
ue the p_ operation. (This is described in more detail 
during the discussion of the FN Framework below). If s 
the p_ operation need not be continued (either ended 
successfully or failed), the results are returned to the 
client application. 



Compound Name SPI 
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The Partial Composite Name SPI required the un- 
derlying context implementation to deal with composite 
names that involve names from more than one naming 
system. Naming Service Providers that only can deal is 
with names from a single naming system should provide 
the Compound Name SPI. 

The Compound Name SPI is designed for Naming 
service providers that only want to deal with names from 
a single naming system. Like the Partial Composite 20 
Name SPI, the Compound Name SPI defines a set of 
operations {cJookupQ, cJistmamesQ, etc) mirroring 
the context operations, except that the operations in the 
Compound Name SPI operate on compound names. 

For context implementations that support static 25 
weak separation, the implementation must supply an 
additional operation tor determining which initial compo- 
nents of the input name belong to the naming system. 
The rest of the components unused by the naming sys- 
tem are returned in another parameter to the operation. 30 
In the preferred embodiment this operation is referred 
to as p_component_parser(). The following code frag- 
ment illustrates how it might be called. 

compound_name - ctx->p_component_parser 
(name, &rest, Apstatus); 35 
where 



naming system after it. Once an operation reaches this 
naming system, it does not enter into another naming 
system in the federation. When a naming system be- 
comes a part of a federation of naming systems, unless 
it is a terminal naming system, it must support the notion 
of being used as an intermediate naming system for res- 
olution of composite names. That means it must provide 
a mechanism for the root of other name spaces to be 
bound and looked up. In the preferred embodiment of 
this invention, this mechanism is referred to as Xhenext 
naming system pointer Different naming services 
have different ways of supporting the next naming sys- 
tem pointer. For example, one naming system might 
support next naming system pointers by giving them 
special names and storing them within the same naming 
system, while another component naming system might 
have a separate service that deals especially with next 
naming system pointers. 

In addition to the c_ interfaces, the Compound 
Name SPI defines an additional set of operations 
(c_lookup_nns(), cjistnames_nns(), etc), mirroring the 
context operations, to manipulate the next name system 
pointer. These "nns" operations take a compound name 
as argument, but operate on the next naming system 
pointer associated with the name, rather than the name 
itself. Figure 12 illustrates the difference between nor- 
mal Compound Name SPI context operations and nns 
Compound Name SPI operations. A call to 

ctx->cJookupCAIB\ & status) 
results in the return of the reference bound to the com- 
pound name "A/B", whereas a call to 

ctx->cJookup_nns{ a A/E?, &status) results in the 
return of the reference bound to the next naming system 
pointer of "A/B". 

Atomic Name SPI 



name is the composite name to be broken up, 
compound_name is the initial components of the 
composite name, name, that are to be processed 40 
by the contexts of this naming system, 
res ris the components of name to be left for the next 
naming system, if any, and 

pstatus is a status parameter which indicated the 
execution status of the p_component_parser() im- 
plementation. 

For example, suppose a context supports static 
weak separation using a syntactic policy that each com- 
ponent belonging to its name space must have an equal so 
('=') character in it. This context implementation supplies 
an implementation for p_component_parser() that, 
when supplied with a composite name such a=b/c=d/e/ 

compound _ name- ctx~>p_componentjparser ss 
( n a=b/c=d/e/f/tf\ & rest, &pstatus): returns in 
compound_name "a=b/c=d", and in rest, m e/f/g". 

A terminai naming system cannot have any next 



The Compound Name SPI required contexts todeal 
with compound names. Naming Service Providers that 
only can deal with atomic names should provide the 
Atomic Name SPI. 

The Atomic Name SPI defines a set of operations 
(aJookup() y aJistnames(), etc), mirroring the context 
operations, for operating on atomic names. In addition, 
the Atomic Name SPI also contains a set of operations 
for dealing with any next naming system pointer asso- 
ciated with the atomic name (a_lookup_nns(), 
a_listnames_nns(), etc). 

The Naming Service Provider using an Atomic SPI 
deals with resolution within a single context which pro- 
vides the basic building block for a hierarchical naming 
service. A context implementation that supplies the 
Atomic Name SPI provides implementations for opera- 
tions on atomic names and any next naming system 
pointers associated with the atomic name. 

A context implementation that supplies the atomic 
SPI expects its input name to be a single string, repre- 
senting the name to be resolved or operated upon in the 
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target context of a naming system. In other words, the 
input name cannot span more than one context. 

A context impiementation that supports strong 
separation (see earlier definitions) must supply an ad- 
ditional operation, c_component_parser(), for parsing a 
compound name into head/tail components using the 
naming convention for that particular naming system. 
(See US Patent No. 5,377,323, which is incorporated 
fully herein by reference, for a description of the protocol 
for parsing a compound name into head/tail compo- 
nents) The input to c_component_parser() is the com- 
pound name, whose first component is to be resolved 
in the target context. The outputs are the first compo- 
nent, head, and the rest of the components, tail, re- 
turned in separate arguments. The lollowing code frag- 
ment illustrates how it might be called. 

head ~ ctx->c_component_parser( compound^ 
name, &tail, Acstatus); 
where 

compound_name is the compound name to be 
parsed, 

head is the first atomic name in compound_name 
according to the naming convention of this context, 
ctx. 

tail is the ordered rest of the atomic names in 
compound_name excluding head; and 
cstatus is a status indicating the success or failure 
of the c_component_parser() operation. 

For example, suppose i:j:k is a compound name 
from a name space that has a left-to-right colon-sepa- 
rated name syntax. The context implementation for this 
naming system supplies an implementation for 
c_component_parser(). When the following is executed. 

head = ctx->c_component_parser("i:j:k", &taii f 
&cstatus); 

headwiW contain V, while tail will contain "j:k tt . 

A context implementation that supports static weak 
separation must supply a routine p_component_parser 
() (described above) for parsing a composite name into 
the initial compound_name and rest components. 

How the FN Framework interacts with contexts that 
export the Atomic Name SPI is described in detail in the 
section THE FEDERATED NAMING FRAMEWORK. 

Summary of SPIs 

In summary, the alternatives for a Naming Service 
Provider to federate using the current invention are: 

(1) Supply implementations for the operations in the 
Composite Name SPI for a composite name-aware 
naming service that is able to deal with any com- 
posite name in its entirety. 

(2) Supply implementations for the operations in the 
Partial Composite Name SPI for a composite name- 
aware naming service that is able to deal with 



names from possibly more than one naming system 
but not necessarily to its entirety. 

(3) Supply implementations for the operations in the 
Compound Name SPI for a naming service that is 

s not composite name-aware. The implementation 
accepts a compound name and performs the con- 
text operation on it. 

(4) Supply implementations forthe operations in the 
Atomic Name SPI for an atomic naming service that 

10 is the building block of a hierarchical naming serv- 
ice. The implementation accepts an atomic name 
and performs the context operation on it. 

C. THE FEDERATED NAMING FRAMEWORK 

is 

The second major element of the present invention 
is the FN Framework shown as block 1108 in Figure 10. 
It is this element which has as its objective to allow new 
and arbitrary naming and directory systems to be made 
20 accessible to applications at run-time, without requiring 
re-compilation, re-linking, or having to stop the applica- 
tion. As described below, the FN Framework provides 
the infrastructure into which the various FN SPI-con- 
forming context implementations described above can 
25 be plugged, and provides the interface to client applica- 
tions which can make the addition of a new naming serv- 
ice transparent to them. 

The FN Framework allows for different implemen- 
tations that supply different FN SPIs to exist at the same 
30 time on a client machine, thereby enabling a client ap- 
plication to access different members of a federation of 
naming services. An example of how the present inven- 
tion is used is depicted in Figure 10. in Figure 10 the 
system 1100 comprises a client application layer 1104 
35 which is capable of handling composite names 1 1 02 and 
which interfaces with a Federated Naming Application 
Programming Interface ("FN API") layer 1106 which is 
located on top of a Federated Naming framework layer 
1108 to which can be interfaced various context imple- 
40 mentatbns for specific naming services 1110, 1112, 
1114 each of which uses a designated FN SPI. The con- 
text implementation 1110 represents the mapping of an 
FN SPI to XDS, an interface for exclusively supporting 
the X.500 directory service 1116. This context imple- 
45 mentation 1110 supports static weak separation and 
supplies the Compound Name SPI. Similarly, the con- 
text implementation 1112 represents the mapping of an 
FN SPI to the Internet DNS resolver API, an interface 
for exclusively supporting the Internet DNS. The context 
so implementation 1112 supports strong separation and 
supplies the Compound Name SPI. And the context im- 
plementation 1114 represents the mapping of an FN SPI 
to the NIS+ API, an interface for exclusively supporting 
NIS+. The context implementation 1114supports strong 
55 separation and supplies the Compound Name SPI. 

Figure 13a illustrates the process employed by the 
FN Framework to take input from the client application, 
and interacting with the appropriate FN SPIs, toaccom- 
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plish the operation on the composite name requested 
by the client application. 

Reterring now to Figure 13a. the client application 
supplies input to the FN Framework 1302 consisting of 
a context handle, a composite name, operation to be 
performed, and one or more additional arguments re- 
quired by the operation (ctx, name, operation A. args) 
1304. The FN Framework first loads in the context im- 
plementation pointed to by the context handle ctx and 
determines which FN SPI is supported by ctx 1306, 
1316, 1340 and 1346. 

FN Framework Interactions with Composite Name 
SPI 

If the context implementation supports Composite 
Name SPI 1308 the FN Framework invokes the opera- 
tion (ctxj) in the context implementation tor ctx appro- 
priate for operation A, supplying it with the arguments 
for the operation (name, args) 1310. The results of per- 
forming this operation are returned to the client applica- 
tion 1312. 

Consider the following example for a context imple- 
mentation that supplies the Composite Name SPI. 

name is "a^b/c-d/e/f/g" (which spans two naming 
systems; "a=b/c=d" belongs to one naming system and 
"e/f/g" belongs to another naming system), 
operation A is VookupQ" 

args is empty (there are no other arguments). The 
FN Framework supplies the arguments ("a=b/c=d/e/f/g", 
"lookupO", {}) to the context implementation (CC1) of 
ctx. CC1 performs the ctxJookupQ operation on the 
composite name "a=b/c=d/e/f/g a as follows: 

ref = ctx->ctxJookup("a=b/c=d/e/f/g tt , &status); 
and returns the result of that operation (ref) to the FN 
Framework, which in turn returns the result to the client 
application. 

The above example illustrates how the FN Frame- 
work employed one context implementation CC1, to 
perform an operation on a composite name that 
spanned two naming systems. CC1 used the Composite 
Name SPI, and therefore is expected to process the 
composite name in its entirety, even when the compos- 
ite name spanned multiple naming systems. Neither the 
Client application that used the FN Framework nor the 
FN Framework itself had any built-in knowledge about 
CC1. The FN Framework used the Composite Name 
SPI to communicate with CC1 . 

FN Framework Interactions with Partial Composite 
Name SPI 

If the context implementation supports Partial Com- 
posite Name SPI 1318 the FN Framework invokes the 
operation (p_) in the context implementation for ctx, ap- 
propriate for operation A supplying it with the argu- 
ments for the operation (name, args) 1320. The context 
implementation returns the results of invoking the p_ op- 



eration and status 1322 to the FN Framework. Upon re- 
turn from the p_ operation, if the status of the operation 
1324 indicates that the operation has gone as far as it 
could (either succeeded or could not be continued) 

5 1334, the FN Framework returns the results of the op- 
eration to the client application 1312. If the status indi- 
cates that the operation needs to be continued 1326, 
the FN Framework extracts information from status 
1328 to continue the operation. The status object con- 

10 tains: 

rname: the remaining part of name that has not yet 
been processed, and 

rref: the reference of the context to continue the op- 
is eration. 

The FN Framework uses rname to update name. In oth- 
er words, rname effectively becomes the new name ar- 
gument to be used in the next iteration through the FN 

20 Framework. The FN Framework also uses rref from the 
status object to construct a new context handle, 
ctx_new. ctx_new\s created by invoking the constructor 
() operation supplied by the context implementation as- 
sociated with rref 1330. ctx is updated to be ctx_new 

2S and effectively becomes the new ctx argument to be 
used in the next iteration through the FN Framework. 
The FN Framework then repeats the procedure for de- 
termining which FN SPI the context implementation of 
the new ctx supports 1332 and then supplies the new 

30 arguments (name, operation A, args) to the new context 
implementation. 

To illustrate the above, consider the following exam- 
ple for a context implementation (PC1 ) that supplies the 
Partial Composite Name SPI. 

3S 

name is u a=b/c=d/e/f/g" (which spans two naming 
systems: u a=b/c=d tt belongs to one naming system 
and "e/f/g" belongs to another naming system). 
operation A is "fookupQ" 
40 args is empty (there are no other arguments). 

The FN Framework supplies the input ("a=b/c=d/e/f/g", 
"lookupO", {}) to the context implementation (PC1) of 
ctx. PC1 performs the pJookupQ operation on the cora- 
45 posite name u a=b/c=d/e/f/g n as follows: 

ref - ctx->p_fookup("a=b/c=d/e/T/g" f &status); 
and returns the result of that operation (ref) to the FN 
Framework. 

Assume lor this example that PC1 processes "a=b/ 
so c=d a and returns a CONTINUE status to the FN Frame- 
work. In addition, it returns two pieces of status informa- 
tion: 

rname - the remaining name ("e/f/g") 
55 - rref - the reference of the context to continue the 
operation, (reference bound to "a-b/c=d"). 

The FN Framework uses rreflo identify the context im- 
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plementation (PC2) to use : and invokes the constructor 
() implementation from PC2 to construct a new context 
handle, ctx_new. The FN Framework replaces the old 
value of ctx with ctx_new. The FN Framework also re- 
places the old value of name with rname. The FN s 
Framework now has sufficient information to continue 
the process. 

Assume that the new ctx also exports the Partial 
Composite Name SPI. The FN Framework supplies ("e/ 
f/g", "lookup() m , {}) to PC2. PC2 performs pJookupQ on to 
the composite name "e/f/g" as follows; 

ref '= ctx->pJookup(* e/f/g*, &status); 
Assume for this example that this operation ends suc- 
cessfully at this point. PC2 returns the reference (ref) 
bound to "e/f/g" Xo the FN Framework, which returns it *5 
to the client application. 

The above example illustrates how the FN Frame- 
work employed two context implementations, PC1 and 
PC2, both of which used the Partial Composite Name 
SPI, to perform an operation on a composite name that 20 
spanned two naming systems. Neither the Client appli- 
cation that used the FN Framework nor the FN Frame- 
work itself had any built-in knowledge about PC1 or 
PC2. The FN Framework used the Partial Composite 
Name SPI to communicate with both PC1 and PC2. 2s 

FN Framework Interactions with Compound Name 
SPI 

If the context implementation supports Compound 30 
Name SPI 1340, the FN Framework executes the algo- 
rithm described by the Compound Name SPI Engine 
1342 (this is shown in detail in Figure 13b). The output 
of the engine are the result of the operation and status 
1344. If the status is CONTINUE 1326, the FN Frame- 3S 
work constructs a new value for name by using the re- 
maining name field (rname) from status 1328. Then, it 
extracts rref from status to construct a context handle 
new_ctx and replaces the old contents of ctx with it. The 
FN Framework then repeats the process from the be- 40 
ginning 1332 using the revised name and context han- 
dle ctx.. If the status is not CONTINUE 1334 the FN 
Framework system returns 1312. 

Referring now to Figure 13b, if the context imple- 
mentation supports the Compound Name SPI, the FN 45 
Framework executes the algorithm described by the 
Compound Name SPI engine 1400 (block 1342 in Fig- 
ure 13a) on the input (c/x, name, operation A, and args) 
1404. In Figure 13b, the FN Framework must first de- 
termine which part of the input, name, is to be processed so 
by this context. That is, because the context supports a 
Compound Name SPLthe FN Framework must obtain 
the compound name, compound_name, for the context 
to work on. The remainder of name unused by this con- 
text is kept in a variable called rest. ss 

If the context implementation supports strong sep- 
aration 1420, compound_name is simply the first com- 
ponent in name and rest is all of name without the first 



component 1422. 

If the context supports static weak separation 1408, 
1412, FN Framework invokes the p_parse_component 
() function supplied by the context implementation to ex- 
tract the initial components (compound_name) of the 
composite name, name, that belongs to the naming sys- 
tem of this context. p_parse_component() returns any 
residual not consumed by this naming system in rest 
1416. 

If the context implementation supports dynamic 
weak separation 1414 t FN Framework uses the entire 
name as compound_name\ox the context implementa- 
tion. This is because the context implementation will de- 
termine dynamically which part of compound_name 
should be consumed and set the remaining name field, 
rname, in status appropriately, resf is set to NULL 141 8. 

At this point, for all the different types of separation, 
FN Framework has compound_namese\ to be the com- 
pound name to supply to the context implementation, 
and rest set to the unused part of name. If rest \s NULL 
1426, compound_name is the last component in name 
to be processed. For this case, FN Framework invokes 
the c_ operation from the context implementation corre- 
sponding to operation A, supplying it with the arguments 
ctx, compound_name and args 1428. If res* is not NULL 
1430, but is the last component in name and is an empty 
string 1434, the Client application is specifying that it 
wants to operate on the next naming system pointer as- 
sociated with compound_name. For this case, FN 
Framework invokes the c_ nns operation from the con- 
text implementation corresponding to operation A, sup- 
plying it with the argument ctx, compound^name and 
args 1436. If rest is not the last component in name or 
if it is the last but not an empty string 1440, the context 
named by compound _name is acting as an intermediate 
context. For this case, the FN Framework invokes the 
operation c_\ookup_nns()\xom the context implementa- 
tion on ctx, compound^nameand args 1442. If the result 
(ref 2) of cJookup_nns() is successful 1448, it would 
contain the reference to the next naming system to con- 
tinue the operation; consequently, upon a successful re- 
turn from c_lookup_nns(), the status is changed to 
CONTINUE 1450 to indicate that the operation should 
be continued and the rref field of status is set to refZ. At 
this point, the FN Framework does the following admin- 
istration of the status object before exiting the Com-, 
pound Name SPI Engine. The rest variable contains the 
part of name that has yet to be processed. Regardless 
of whether the operation succeeded, rest must be ap- 
pended to the rname field of the status object, ensuring 
that rname accurately indicates the remaining part of 
name that still needs further processing 1437. The FN 
Framework then exits the Compound Name SPI Engine 
and continues at 1344 in Figure 13a (this is described 
in detail above in the Partial Composite Name section). 

To illustrate the above, consider the following exam- 
ple for a context implementation (C1) that supplies the 
Compound Name SPI. 
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name is "a=b/c=d/e/f/g " (which spans two naming 
systems; "a=b/c=d" belongs to one naming system and 
"e/f/g" belongs to another naming system). 

operation A is "lookupQ" 5 
args is empty (there are no other arguments). 

Assume for this example that C1 supports static weak 
separation. 

The FN Framework invokes p_component_parser io 
QUom C1 in order to extract compound _narr\e and rest 
arguments. 

compound_name ~ ctx->p_component_parser 
("a=b/c=d/e/f/g u , &rest, &pstats); 

Assume that p_component_parser() in C1 uses the *5 
equal character ('=') to determine which components of 
the name belong to its naming system. 
compound jname then contains "a=b/c=d"', rest con- 
tains "e/f/g M . Because rest is neither null or the last com- 
ponent, the context named by "a=b/c=d" is in an inter- 20 
mediate naming system. Tne FN Framework supplies 
the input ( tt a=b/c=d u f "lookup__nns() u , #) to the context 
implementation (C1) of ctx. C1 performs the 
cJookup_nns() operation on the compound name "a=b/ 
c=d'\ 2S 

ref2 - ctx->cJookup_nns("a=b/c=d u , &status); 
and returns the result of that operation (ref2) to the FN 
Framework. 

Assume for this example that this operation suc- 
ceeded. The FN Framework then sets status to CON- 30 
TINUE and sets the resolved reference field, rref, of sta- 
tus to ref2. It appends rest to the remaining name field, 
rname ot status. 

rname {"e/f/g") 35 
rref (result of c_lookup_nns("a=b/c=d", .„) opera- 
tion) 

The FN Framework then uses rrefto identify the context 
implementation (C2) to use, and invokes the constructor 40 
() implementation from C2 to construct a new context 
handle, ctx_new. The FN Framework replaces the old 
value of ctx with ctx_new. The FN Framework replaces 
the old value of name with rname. The FN Framework 
now has sufficient information to continue the process. -*s 

Assume that C2 supplies the Compound Name SPI 
and supports dynamic weak separation. The FN Frame- 
work sets rest to NULL and supplies the input ("e/f/g", 
"lookup_up() u , {}) to C2. C2 performs cJookupQ on the 
composite name "e/f/g n as follows: 50 

ref = ctx->cJookup( m e/f/g a , &status); 
Assume for this example that this operation ends suc- 
cessfully at this point. C2 returns the reference {ref) 
bound to "e/f/g" Xo the FN Framework. Because rest is 
NULL, no update to the contents of status is required. 55 
The FN Framework returns ref to the client application. 

The above example illustrates how the FN Frame- 
work employed two context implementations C1 and 



C2, both of which used the Compound Name SPI, to 
perform an operation on a composite name that 
spanned two naming systems. C1 supported static 
weak separation while C2 supported dynamic weak 
separation. Neither the Client application that used the 
FN Framework nor the FN Framework itself had any 
built-in knowledge about C1 or C2. FN Framework used 
the Compound Name SPI to communicate with both C1 
and C2. 

FN Framework Interactions with Atomic SPI 

Returning now again to Figure 13a, if the context 
implementation supports Atomic Name SPI 1346, the 
FN Framework executes the algorithm described by 
Atomic Name SPI Engine 1348 (this is shown in detail 
in Figure 13c). The output of the engine are the result 
of the operation and status 1350. If the status is CON- 
TINUE 1326, the FN Framework constructs a new value 
for name by using the remaining name field (rname) 
from status 1323. Then, it extracts rref from status to 
construct a context handle new_ctxand replaces the old 
contents of ctx with it. The FN Framework then repeats 
the process from the beginning 1332 using the revised 
name and context handle ctx. If the status is not continue 
1334 the FN Framework system returns 1312. 

If the context implementation supports the Atomic 
Name SPI (1346 in Figure 13a), the FN Framework ex- 
ecutes the algorithm described in the Atomic Name SPI 
engine 1500 in Figure 13c. In Figure 13c the FN 
Framework must first determine which part of the input, 
name, is to be processed by this context. That is, be- 
cause the context supports an Atomic Name SPI, the 
FN Framework must obtain the atomic name, head, for 
the context to work on. It does this in two steps. First it 
needs to get the compound name, compound_name t 
from name, and then, from compound_name, the atom- 
ic part, head, to process. The remainder of name not 
part of compound_name is kept in a variable called rest 
The remainder of compound_name not part of head is 
kept in a variable called tail. 

If the context supports strong separation 1508, 
compound_name is simply the first component in name 
and rest is all of name without the first component 1510. 
The FN Framework then invokes the c_parse_compo- 
nentQ function (described earlier) supplied by the con- 
text implementation to extract the atomic component 
(head) to process, c _parse_component() also returns 
the rest of compound jname without head in tail 1512. 

If the context supports static weak separation 1514 
1518, the FN Framework invokes the p_parse__compo- 
nentQ function (described earlier) supplied by the con- 
text implementation to extract the initial components 
(compound_name) of the composite name, name, that 
belongs to the naming system of this context 1520. 
p_parse_component() returns any residual not con- 
sumed by this naming system as resf 1522. 

If the context implementation supports dynamic 
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weak separation 1524, the FN Framework uses the en- 
tire name as compound_name for the context imple- 
mentation. This is because the context implementation 
will determine dynamically which part of 
compound_name should be consumed and set the re- s 
turn status appropriately, rest is set to NULL 1526. 

For both forms of weak separation, headis the first 
component in compound_name and tail is the rest of 
compound_name without head 1522. 

At this point, for all the different types of separation, 10 
FN Framework has compound_nameset to be the com- 
pound name that belongs to the naming system of this 
context, ctx, and rest set to the unused part of name. 
Furthermore, head is set to the atomic name from 
compound _name\o be processed by ctx and tail is set ts 
to the rest of compound^ name. 

If tail is not NULL 1560, then there are more atoms 
to be processed in compound_name than just head and 
that the context named by headis an intermediate con- 
text within the same naming system. FN Framework in- 20 
vokes aJookupQ from the context implementation on 
headto obtain the reference (ref2) bound to head1S62. 
After invoking aJookupQ, the FN Framework inserts the 
contents of tail as the first component(s) in rest to ac- 
count for the components not yet processed by this con- 25 
text implementation 1564. rest is appended to the con- 
tents of the remaining field, rname, of the status object 
1537. If the operation is successful 1552, FN Frame- 
work sets the status of the operation to CONTINUE 
1554 to indicate that the operation needs to be contin- 30 
ued, and sets the resolved reference field (rref) of status 
to ref2. The FN Framework then exits the engine 1538. 

If tail is NULL 1530, then head is the last atom to 
be processed in the naming system associated with ctx. 
If rest is NULL 1534, then the target context has been 35 
reached; the FN Framework invokes the a_ operation 
from the context implementation corresponding to oper- 
ation A 1536 and exits the engine 1538. 

If tail is NULL 1530 but rest is not the last and empty 
component in name 1544, then the context named by 40 
headis an intermediate context connecting this naming 
system to the next. The FN Framework invokes the op- 
eration aJookup_nns()or\ headXo obtain the reference 
(ref2) to the next context (in the next naming system) to 
contin ue the operation 1 546. If the operation is success- 
ful 1552, FN Framework sets the status to CONTINUE 
1554 to indicate that the operation should be continued, 
and sets the resolved reference field (rref) in status to 
be (ref2), and exits the engine 1538. 

If tail is NULL 1530 but rest is the last and empty so 
component in name 1556, then the operation is to be 
effected on the next naming system associated with 
head. FN Framework invokes the a_nns operation from 
the context implementation with the arguments ctx, 
head, and args 1558 and then exits the engine 1538. ss 

Upon exit from the Atomic Name SPI Engine 1350, 
the FN Framework continues as described above for 
Partial Composite Name section (1324 in Figure 13a). 
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To illustrate the above, consider the following exam- 
ple for a context implementation (A1 ) that supplies the 
Atomic Name SPL 

name is °a= b/c=d/e/f/g' (which spans two naming 
systems: a a~b/c=d" belongs to one naming system and 
"e/f/g" belongs to another naming system). 

operation A is "lookupQ" 

args is empty (there are no other arguments). 

Assume for this example that A1 supports static weak 
separation. 

The FN Framework invokes p_component_parser 
() from A1 in order to extract compound_name and rest 
arguments. 

com pounds name = ctx->p_component_parser 
( u a=b/c=d/e/f/g°, &rest, &pstats); 
Assume that p_component_parser() in A1 uses the 
equal character ('=') to determine which components of 
the name belong to its naming system. 
compound_name then contains "a=b/c=d"; rest con- 
tains "e/f/g". FN Framework then extracts head and tail 
from compound_name: head becomes "a=b", tail be- 
comes "c=d". Because tail is not NULL, the context 
named by u a=b" is an intermediate context within the 
same naming system. The FN Framework supplies the 
input ("a^b", "lookupQ", Q) to the context implementa- 
tion (A1) of ctx. A1 performs the a_lookup() operation 
on the atomic name "a-b" as follows: 

ref2~ ctx->a_lookup( u a=b", &status); 
and returns the result of that operation (ref2) to the FN 
Framework. 

Assume for this example that this operation suc- 
ceeded. The FN Framework then sets status to CON- 
TINUE and sets the resolved reference field, rref, of sta- 
tus to ref2. It then inserts tail ("c=:d") in front of rest("e/ 
f/g")\ this ("<z=d/e/f/g") becomes the new rest The FN 
Framework then appends rest to the remaining name 
field, rname of status. 

rname ("c=d/e/f/g") 

rref (result of a_lookup("a=b u , .. .) operation) 

FN Framework resets rest to NULL The FN Framework 
then uses rref to construct the handle to the next context 
object. FN Framework supplies rref to the constructorQ 
implementation from A1 to construct a new context han- 
dle, ctx_new. The FN Framework replaces the old value 
of cfcrwith ctx_new. The FN Framework replaces the old 
value of name with rname ("c=d/e/f/g"). The FN Frame- 
work now has sufficient information to continue th e proc- 
ess. 

The FN Framework supplies the input ("c=d/e/f/g", 
u lookup_up()*, {}) to Al . Following the Atomic Name SPI 
Engine, through this iteration, head is "c=d u and tail ls 
NULL, rest ("e/f/g") is the last and empty component in 
name, which means that the context named by u c=d" is 
the last context in an intermediate naming system. FN 
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Framework invokes aJookup_nns() on "c=d" to get a 
reference to the next naming system to continue the op- 
eration. 

A1 performs ajookup_nns() on the atomic name "c=d" 
as follows: 5 

ref2 = ctx->aJookup_nns( n c=d", &status); 
Assume for this example that this operations ends suc- 
cessfully at this point. A1 returns the reference (ref2) 
bound to the next naming system of "c=d" to the FN 
Framework. The FN Framework then sets the status of 10 
the operation to CONTINUE, sets the resolved refer- 
ence part (net) of the status to ref2, and appends rest 
("e/f/g') to the remaining name (rname) part in status. 

At this point, FN Framework has resolved to the 
next naming system pointed to by "a=b/c=d n and must is 
continue the operation on "e/f/g". Assume for this exam- 
ple that the context implementation C2 associated with 
the new rref supplies the Compound Name SPI using 
dynamic weak separation. The FN Framework sets rest 
to NULL and supplies the input ("e/f/g", "lookup jupQ" , 20 
{}) to C2. C2 performs cJookupQ on the composite 
name "e/f/g" as follows: 

ref '= ctx->c_lookup( B e/f/g\ dstatus); 
Assume for this example that this operations ends suc- 
cessfully at this point. C2 returns the reference (ref) 2s 
bound to "e/f/g" to the FN Framework. Because "e/f/g" 
was the last component in name (i.e. rest is NULL), no 
update to the contents of status is required. The FN 
Framework returns ref to the client application. 

The above example illustrates how the FN Frame- 30 
work employed two context implementations, A1 and C2 
to perform an operation on a composite name that 
spanned two naming systems. A1 was a context imple- 
mentation that used the Atomic Name SPI and support- 
ed static weak separation. C2 was a context impiemen- 35 
tation that used the Compound Name SPI and support- 
ed dynamic weak separation. Neither the Client appli- 
cation that used the FN Framework nor the FN Frame- 
work itself had any built-in knowledge about A1 or C2. 
FN Framework communicated with A1 using the Atomic 40 
Name SPI and communicated with C2 using the Com- 
pound Name SPI. 

The above detailed descriptions indicate the pre- 
ferred embodiment at this time. However, those skilled 
in the art will recognize that various similar impiemen- 45 
tations of these operations are possible and are within 
the scope of the present invention. 

D. Context Implementation Linkage 

so 

The third element of the present invention is the 
mechanism used by the FN Framework to invoke differ- 
ent context implementations. 

In the preferred embodiment, a context implemen- 
tation gets linked to an application by the use of con- ss 
structors. All access to a context is via its context handle. 
The context handle is obtained by calling a constructor, 
named using a pre-defined scheme described below, 



that may call other internal constructors specific to the 
FN SPI. The FN SPi constructors return handles to con- 
text objects that supply the appropriate FN SPI, using a 
scheme similar to that described in Figure 6. Subse- 
quent operations involving the context handle will trigger 
the corresponding operation supplied by the context im- 
plementation via the FN SPI. 

Figure 10 illustrates the relationship between con- 
text implementations-1110, 1112, 1114, naming services 
1 1 1 6, 1 1 1 8, 1 1 20 an d th e F N framework 1 1 08. Code for 
a particular context implementation is uniquely identified 
using the context's reference and address type(s). The 
constructors located within context implementations are 
also uniquely identified using the context's reference 
and address type(s). For example, as illustrated earlier, 
the following illustrates a code fragment of how the con- 
structor might be called: 

ctx = constructor(reference): where 

ctx is a handle to a context object 

reference is a reference obtained by looking up a 

name. 

New and arbitrary naming and directory services 
are made accessible to applications without being rec- 
ompiled because of the architecture of the FN Frame- 
work and its definition and use of the FN SPI. The FN 
Framework has no dependencies on particular context 
implementations, only on the interface (FN SPI) provid- 
ed by the context implementations. Because of this, the 
FN Framework is able to select different context imple- 
mentations to use upon demand through the use of the 
constructors, without any changes to the FN Framework 
or the client application. 

When the operating environment in which the FN 
Framework and context implementations are deployed 
has support for dynamic linking, the application gains 
the further advantage that it need not be re-linked or 
stopped. When dynamic linking is available, the FN 
Framework is able to link in different context implemen- 
tations dynamically upon demand by use of the con- 
structors, thereby, not requiring the application to be 
linked beforehand with all possible context implementa- 
tions that it might need. 

It will be appreciated by those skilled in the art that 
various modifications and alterations may be made in 
the preferred embodiments of the invention disclosed 
herein without departing from the scope of this inven- 
tion. Accordingly, the scope of the invention is not to be 
limited to the particular invention embodiments dis- 
cussed above, but should be defined only by the claims 
set forth below and equivalents thereof. 



Claims 

1. A Federated Naming Framework System for use in 
a distributed computer system, having at least one 
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computer having a central processing unit, a mem- 
ory, a display and an input/output mechanism, to 
provide an interface system between a client appli- 
cation configured to use a composite name span- 
ning two or more naming systems and a naming s 
service mechanism for use in resolving the compos- 
ite name, said Federated Naming Framework Sys- 
tem comprising: 

a federated naming framework mechanism in io 
the computer memory, coupled to said client 
application and configured to resolve a com- 
posite name of an object by use of a naming 
service mechanism; 

one or more naming service mechanisms con- 15 
figured to conform to a federated naming serv- 
ice provider interface and coupled to the feder- 
ated naming framework mechanism; and 
the one or more naming service mechanisms 
configured to indicate support for strong or 20 
weak separation in their respective naming sys- 
tems. 

2. The Federated Naming Framework System of claim 

1 wherein said naming service mechanism is locat- 2s 
ed by the federated naming framework mechanism 
by use of a constructor mechanism. 

3. The Federated Naming Framework System of claim 

1 wherein the federated naming framework mach- 30 
anim uses a context handle provided by the client 
application to identify a related context implemen- 
tation and to determine which federated naming 
service provider interface this context implementa- 
tion supports. 35 

4. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
mechanism is configured to communicate with an . 
atomic naming service provider. 40 

5. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
mechanism is configured to communicate with a 
compound naming service provider. 4 & 

6. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
mechanism is configured to communicate with a 
partial composite naming service provider. 50 

7. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
mechanism is configured to communicate with a 
composite naming service provider. 55 

8. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
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mechanism is configured to communicate with a 
compound naming service provider and an atomic 
naming service provider 

9. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
mechanism is configured to communicate with a 
partial composite naming service provider and a 
compound naming service provider. 

10. The Federated Naming Framework System of claim 
1 wherein said naming service provider interface 
mechanism is configured to communicate with a 
partial composite naming service provider and a 
compound naming service provider and an atomic 
naming service provider. 

11. An improved method for resolving a composite 
name of an object, the composite name used by a 
client application in a distributed computer system, 
having at least one computer having a central 
processing unit, a memory, a display and an input/ 
output mechanism, the method comprising the 
steps of: 

providing a federated naming framework mech- 
anism in the computer memory, configured to 
be callable by the client application and config- 
ured to resolve the composite name of the ob- 
ject by use of a naming service mechanism, the 
naming service mechanism comprising a con- 
text implementation conforming to a designat- 
ed federated naming service provider interface; 
under computer control, the client application 
calling the federated naming framework mech- 
anism, the client application supplying inputs 
comprising a context handle, a composite 
name, a designated operation to be performed 
and one or more arguments required by the op- 
eration; 

the federated naming framework mechanism 
using the context handle to load a context im- 
plementation pointed to by the context handle 
and determining which federated naming serv- 
ice provider interface the context implementa- 
tion supports; 

the federated naming framework mechanism 
invoking a first operation appropriate to a nam- 
ing service provider interface supported by the 
context implementation and appropriate to the 
designated operation called by the client appli- 
cation, the first operation invoked on the con- 
text implementation, 

the context implementation returning the re- 
sults of the invoked first operation and returning 
a status value to the federated naming frame- 
work mechanism; 

if the status value indicates that the first oper- 
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ation either succeeded, thereby having re- 
solved the composite name, or could not be 
continued, the federated naming framework 
mechanism returning the results of the first op- 
eration to the client application ; and 
if the status value indicates that the operation 
should be continued, the federated naming 
framework mechanism continues to process a 
remainder of the composite name based on the 
status information returned. 

12. The method of claim 1 1 wherein the federated nam- 
ing framework mechanism using the context handle 
to load a context implementation pointed to by the 
context handle and determining which federated 
naming service provider interface the context imple- 
mentation supports comprises the additional steps 
of: 

determining that the federated naming service 
provider interface supported is a Compound 
Name service provider interface; 
determining which part of the composite name 
supplied by the client application is to be proc- 
essed by a context implementation related to 
the Compound Name service provider interface 
by the following steps: 

if the context implementation related to the 
Compound Name service provider inter- 
face supports strong separation then using 
a first component of the composite name 
as a designated part of the composite 
name supplied by the client application is 
to be processed; 

if the context implementation related to the 
Compound Name service provider inter- 
face supports static weak separation then 
using a parse-component mechanism sup- 
plied by the context implementation related 
to the Compound Name service provider 
interface to extract initial components of 
the composite name that belong to a nam- 
ing system supported by the context imple- 
mentation related to the Compound Name 
service provider interface, which initial 
components are to be used as the desig- 
nated part of the composite name supplied 
by the client application is to be processed; 
and 

if the context implementation related to the 
Compound Name service provider inter- 
face supports dynamic weak separation 
then using the entire composite name as 
the designated part of the composite name 
supplied by the client application is to be 
processed. 



13. The method of claim 11 wherein the federated nam- 
ing framework mechanism using the context handle 
to load a context implementation pointed to by the 
context handle and determining which federated 

5 naming service provider interface the context imple- 
mentation supports comprises the additional steps 
of: 

determining that the federated naming service 
10 provider interface supported is a Composite 

Name service provider interface; and 
using the entire composite name as the desig- 
nated part of the composite name supplied by 
the client application which is to be processed 
is by the context implementation. 

14. The method of claim 11 wherein the federated nam- 
ing framework mechanism using the context handle 
to load a context implementation pointed to by the 

20 context handle and determining which federated 
naming service provider interface the context imple- 
mentation supports comprises the additional steps 
of: 

25 determining that the federated naming service 

provider interface supported is a Partial Name 
service provider interface; and 
using the entire composite name as the desig- 
nated part of the composite name supplied by 
the client application which is to be processed 
by the context implementation. 

15. The method of claim 11 wherein the federated nam- 
ing framework mechanism using the context handle 
to toad a context implementation pointed to by the 
context handle and determining which federated 
naming service provider interface the context imple- 
mentation supports comprises the additional steps 
of: 

determining that the federated naming service 
provider interface supported is an Atomic 
Name service provider interface; 
determining which part of the composite name 
supplied by the cfient application is to be proc- 
essed by a context implementation related to 
the Atomic Name service provider interface by 
the following steps: 

if the context implementation related to the 
Atomic Name service provider interface 
supports strong separation then using a 
parse-atomic-component mechanism sup- 
plied by the context implementation related 
to the Atomic Name service provider inter- 
face to extract a first atomic component 
(head) from a first component of the com- 
posite name as a designated part of the 
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composite name supplied by the client ap- 
plication which is to be processed; 
it the context implementation related to the 
Atomic Name service provider interface 
supports static weak separation then using 
a parse-component mechanism supplied 
by the context implementation related to 
the Atomic Name service provider inter- 
face to extract an ordered list of initial com- ' 
ponents of the composite name that belong 
to a naming system supported by the con- 
text implementation related to the Atomic 
Name service provider interface, and from 
this ordered list of initial components, ex- 
tract a first component to be used as the 
designated part of the composite name 
supplied by the client application which is 
to be processed; and 
if the context implementation related to the 
Atomic Name service provider interface 
supports dynamic weak separation then 
using the entire composite name as the 
designated part of the composite name 
supplied by the client application which is 
to be processed. 

16. The method of claim 11 wherein said naming serv- 
ice provider interface mechanism is further config- 
ured to communicate with one or more naming serv- 
ices. 
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17. The method of claim 11 wherein said naming serv- 
ice provider interface mechanism is further config- 
ured to communicate with a compound naming 
service provider and an atomic naming service pro- 
vider. 

18. The method of claim 11 wherein said naming serv- 
ice provider interface mechanism is further config- 
ured to communicate with a partial composite nam- 
ing service provider and a compound naming serv- 
ice provider. 

19. The method of claim 11 wherein said naming serv- 
ice provider interface mechanism is further config- 
ured to communicate with a partial composite nam- 
ing service provider and a compound naming serv- 
ice provider and an atomic naming service provider. 

20. A computer program product comprising: 

a computer usable medium having computer 
readable program code mechanisms embodied 
therein configured to resolve a composite name of 
an object called by a client application., the compos- 
ite name spanning two or more naming systems, 
the computer readable program code mechanisms 
in said computer program product comprising: 



35 



40 



45 



computer readable code mechanisms config- 
ured to accept a call from the client application 
to resolve the composite name by a federated 
naming framework mechanism, configured to 
further use a naming service mechanism to per- 
form a name resolution; 
computer readable code mechanisms config- 
ured to contain one or more naming service 
mechanism which conform to a federated nam- 
ing service provider interface wherein the one 
or more naming service mechanisms have no 
direct connection to the client application; and 
computer readable code mechanisms config- 
ured to cause the one or more naming service 
mechanisms to indicate their support for strong 
or weak separation in their respective naming 
systems. 

21 . The computer program product of claim 20 wherein 
a naming service mechanism to be connected to the 
federated naming framework mechanism is located 
by the federated naming framework mechanism by 
use of a constructor mechanism. 

22. A computer program product comprising: 

a computer usable medium having computer 
readable program code mechanisms embodied 
therein configured to resolve a composite name of 
an object called by a client application, the compu- 
ter readable program code mechanisms in said 
computer program product comprising: 

computer readable code mechanisms config- 
ured to accept a call from the client application 
to resolve the composite name by a federated 
naming framework mechanism, configured to 
further use one or more naming service mech- 
anisms to perform a name resolution, said one 
or more naming service mechanisms located 
by use of a constructor mechanism; and 
computer readable code mechanisms config- 
ured to cause the one or more naming service 
mechanisms each of which provides a naming 
service, to be configured to conform to a feder- 
ated naming service provider interface and to 
indicate support for strong or weak separation 
in their respective naming systems. 
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23. A computer program product comprising: 

a computer usable medium having computer 
readable program code mechanisms embodied 
therein configured to resolve a composite name of 
an object called by a client application, the compu- 
ter readable program code mechanisms in said 
computer program product comprising: 

computer readable code mechanisms config- 
ured to accept a call from the client application 
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to resolve the composite name by a federated 
naming framework mechanism, configured to 
further use one or more naming service mech- 
anisms to perform a name resolution; and 
computer readable code mechanisms config- 
ured to cause the naming service mechanisms 
to be connected tothe federated naming frame- 
work mechanism in accordance with a federat- 
ed naming service provider interface wherein a 
new naming service mechanism can be con- 
nected to the federated naming framework 
mechanism without impact to the client appli- 
cation. 
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27. 



24. The computer program product in claim 23 wherein 
the federated naming framework mechanism lo- 26. 
cates the one or more naming service mechanisms 

to perform a name resolution by use of a constructor 
mechanism. 

25. A method for resolving a composite name of an ob- 
ject, the composite name used by a client applica- 
tion in a distributed computer system, having at 
least one computer having a central processing 
unit, a memory, a display and an input/output mech- 
anism, the method comprising the steps of: 

providing a federated naming framework mech- 
anism in the computer memory, configured to 
be callable by the client application and config- 
ured to resolve the composite name of the ob- 
ject by use of a naming service mechanism, the 
naming service mechanism comprising a con- 
text implementation conforming to a designat- 
ed federated naming service provider interface; 
providing a process to allow the client applica- 
tion to call the federated naming framework 
mechanism, the client application supplying in- 
puts comprising a context handle, a composite 
name, a designated operation to be performed 
and one or more arguments required by the op- 
eration; 

providing a process to allow the federated nam- 
ing framework mechanism to use the context 
handle to load a context implementation point- 
ed to by the context handle and to determine 
which federated naming service provider inter- 
face the context implementation supports; 
providing a process to allow the federated nam- 
ing framework mechanism to invoke a first op- so 28. 
eration appropriate to a naming service provid- 
er interface supported by the context imple- 
mentation and appropriate to the designated 
operation called by the client application, the 
first operation to be invoked on the context im- ss 
plementation, 

providing a process to allow the context imple- 
mentation to return the results of the invoked 
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first operation and to return a status value to 
the federated naming framework mechanism; 
if the status value indicates that the first oper- 
ation either succeeded, thereby having re- 
solved the composite name, or could not be 
continued, providing a process to allow the fed- 
erated naming framework mechanism to return 
the results of the first operation to the client ap- 
plication, and 

if the status value indicates that the first oper- 
ation should be continued, providing a process 
to allow the federated naming framework 
mechanism to continue processing a remain- 
der of the composite name. 

The method of claim 25 wherein the step of provid- 
ing a process to allow the federated naming frame- 
work mechanism to use the context handle to load 
a context implementation pointed to by the context 
handle and to determine which federated naming 
service provider interface the context implementa- 
tion supports comprises the additional steps of: 

providing a process to determine that the fed- 
erated naming service provider interface sup- 
ported is a Composite Name service provider 
interface; and 

providing a process to use the entire composite 
name as the designated part of the composite 
name supplied by the client application to be 
processed. 

The method of claim 25 wherein the step of provid- 
ing a process to allow the federated naming frame- 
work mechanism to use the context handle to toad 
a context implementation pointed to by the context 
handle and to determine which federated naming 
service provider interface the context implementa- 
tion supports comprises the additional steps of: 

providing a process to determine that the fed- 
erated naming service provider interface sup- 
ported is a Partial Composite Name service 
provider interface; 

providing a process to use the entire composite 
name as the designated part of the composite 
name supplied by the client application to be 
processed. 

The method of claim 25 wherein the step of provid- 
ing a process to allow the federated naming frame- 
work mechanism to use the context handle to load 
a context implementation pointed to by the context 
handle and to determine which federated naming 
service provider interface the context implementa- 
tion supports comprises the additional steps of: 

providing a process to determine that the fed- 
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erated naming service provider interface sup- 
ported is a Compound Name service provider 
interface; 

providing a mechanism to determine which part 
of the composite name supplied by the client 
application is to be processed by a context im- 
plementation related to the Compound Name 
service provider interface by the following 
steps: 

if the context implementation related to the 
Compound Name service provider inter- 
face supports strong separation then using 
a first component of the composite name 
as a designated part of the composite 
name supplied by the client application to 
be processed; 

if the context implementation related to the 
Compound Name service provider inter- 
face supports static weak separation then 
using a parse-component mechanism sup- 
plied by the context implementation related 
to the Compound Name service provider 
interface to extract initial components of 
the composite name that belong to a nam- 
ing system supported by the context imple- 
mentation related to the Compound Name 
service provider interface, which initial 
components are to be used as the desig- 
nated part of the composite name supplied 
by the client application to be processed; 
and 

if the context implementation related to the 
Compound Name service provider inter- 
face supports dynamic weak separation 
then using the entire composite name as 
the designated part of the composite name 
supplied by the client application to be 
processed. 

29. The method of claim 25 wherein the step of provid- 
ing a process to allow the federated naming frame- 
work mechanism to use the context handle to load 
a context implementation pointed to by the context 
handle and to determine which federated naming 
service provider interface the context implementa- 
tion supports comprises the additional steps of: 
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if the context implementation related to the 
Atomic Name service provider interface 
supports strong separation then using a 
parse-atomic-component mechanism sup- 
plied by the context implementation related 
to the Atomic Name service provider inter- 
face to extract a first atomic component 
(head) from a first component of the com- 
posite name as a designated part of the 
composite name supplied by the client ap- 
plication which is to be processed; 
if the context implementation related to the 
Atomic Name service provider interface 
supports static weak separation then using 
a parse-component mechanism supplied 
by the context implementation related to 
the Atomic Name service provider inter- 
face to extract an ordered list of initial com- 
ponents of the composite name that belong 
to a naming system supported by the con- 
text implementation related to the Atomic 
Name service provider interface, and from 
this ordered list of initial components, ex- 
tract a first component to be used as the 
designated part of the composite name 
supplied by the client application which is 
to be processed; and 
if the context implementation related to the 
Atomic Name service provider interface 
supports dynamic weak separation then 
using a first component from the entire 
composite name as the designated part of 
the composite name supplied by the client 
application which is to be processed. 



providing a process to determine that the fed- 
erated naming service provider interface sup- 
ported is a Atomic Name service provider inter- 
face; 

providing a mechanism to determine which part 
of the composite name supplied by the client 
application is to be processed by a context im- 
plementation related to the Atomic Name serv- 
ice provider interface by the following steps: 
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PARTIAL COMPOSITE NAME RESOLUTION 




<operation results>= ctx->p— <operation>(name t status); 



code = CONTINUE 
resolved_reference 
remaining_name 




ctx = p_from_ ref (resolved - reference, status); 



FIG. II 



COMPONENT NAMES AND NEXT NAMING SYSTEM POINTERS 
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